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1.0 INTRODUCTION 


1.1 BACKGROUND 

During the last decade, the need for automation technology In NASA 
advanced missions has become apparent. This trend has been driven by many 
factors Including the following: 

Cost of Ground Support - Current ground operations are reliant on large 
teams of specialists to perform functions such as fault detection, fault 
Isolation, failure mode workaround, command processing, and tracking 
processing. It Is becoming less feasible to maintain these large cadres 
of technical people during flight operations due to economic limitations. 
Furthermore, these Individuals In a typical operation scenario are under- 
utilized until a failure occurs. With the maturing of decision-aiding 
techniques such as expert systems. It Is becoming feasible to supplement 
Individuals with aids that more effectively extract Information from the 
ever-lncreaslng volume of data. This, In turn, will enable the large 
cadres of Individuals to be significantly reduced while Increasing the 
ability of operators to make decisions effectively. 

Man Support In Hazardous Environments - The cost of supporting man In the 
hostile space environment Is necessarily much larger than that of 
supporting an unmanned system. Manned vehicles must incorporate costly 
life support systems which decrease vehicle payload capacity. The quality 
of components and level of redundancy for manned vehicles must be higher 
than those for unmanned missions. However, human problem solving capa- 
bilities are still required for many applications. For some near-term 
applications. It will be feasible to automate the control process In order 
to remove man from the vehicle. For more complex operations, problem 
solving abilities may be remotely incorporated through telepresence and 
remote manrln-the-loop control. As the state of the art in automated 
problem solving advances, the individual can be removed from the control 
loop and will become a supervisor over an automated system. 

Non-Optlmal Human Control - Laboratory studies have shown that if good 
models of the system dynamics and appropriate control laws can be 
developed and Implemented In real time, an automated system provides more 
optimal control than does a man In the loop. This has been demonstrated 
during physical simulations of rendezvous and docking but applies as well 
to other areas such as manipulator control. 

Pyschologlcal Considerations - When placed in a hlghly-repetitive, mundane 
environment, humans have a tendency to become lackadaisical and make 
mistakes. Many of the tasks inherent in space operations and ground 
support have this quality. Decision aids In this environment would reduce 
the repetition and provide a means to quickly evaluate the volumes of 
data, provide a synopsis of the data, generate recommendations, and allow 
the human to use the inherent powers of reasoning more effectively. 

Limited Strength - For many application scenarios such as payload 
retrieval, limited human strength becomes a negative factor. Furthermore, 
human dexterity Is significantly reduced by the cumbersome life support 
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equipment required In space. With the state of the art in actuators and 
materials, it is possible to develop mechanisms that deliver more torque 
with faster response times than a human counterpart. 

The current state of robotics is limited to relatively-slmple, pre- 
programmed tasks with little or no machine intelligence and very 
restricted sensing of environments. For the more complex and dynamic 
environment associated with space applications, it is still necessary to 
incorporate man in the control loop. In order to achieve the ambitious 
goals of the space program in areas such as space station and long-life 
reserviceable spacecraft, it is essential to reduce direct human control 
of the robotic systems. This reduction can most naturally occur over a 
foui^-phase development process. 

The first phase is to develop the required system with man in the loop to 
provide control and problem solving functions. The second phase of 
robotic system evolution is to extract the man from the primary control 
loop to assume a supervisory role. In this role, the operator will 
perform the functions of planning out a sequence of tasks to achieve a 
specific goal. The robotic system will perform the tasks of trajectory 
planning, obstacle avoidance, and joint control. In the third phase, the 
individual will be extracted one more level. In this phase, the operator 
will perform the function of establishing intermediate goals for the 
robotic system. The robotic system will perform the functions associated 
with breaking down the specific goals into individual tasks to be per- 
formed. The final phase of robotic evaluation is the development of a 
fully-autonomous robotic system. 


1.2 CONTRACT OBJECTIVES 

This contract supports an effort: 

1) to bring within NASA, machine intelligence methodologies in automated 
decision making, and 

2) to develop an integrated robotic system simulation as a testbed for 
applying and extending this technology. 

Specifically, the purpose of this Investigation is to provide a basis for 

the development of a robotics simulation (ROBSIM) computer program by: 

1) Identifying and evaluating applicable artificial intelligence 
techniques; 

2) Defining the framework of the simulation — the structure of the 
software, dynamic equations, algorithms for control and decision 
making, etc.; 

3) Developing mathematical models of manipulator components; 

4) Developing a graphics display. 

Development of the complete simulation software system is not within the 

scope of this contract. 
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1.3 REPORT ORGANIZATION 

This document covers the work performed on Task 1 through Task 7 of 
Contract NASl-16759, "Evaluation of Automated Decision-Making Methodology 
and Development of Integrated Robotic System Simulation," for the Langley 
Research Center of the National Aeronautics and Space Administration. It 
was prepared by Martin Marietta Corporation in accordance with the 
contract. Part II, Statement of Work. 

This document consists of six sections and five appendices. Section 1,0 
provides an introduction. Section 2.0 contains the results of Task 1 and 
Task 2 activities regarding artificial intelligence techniques. Section 

3.0 provides a description of the robotic simulation tool developed under 
this contract and covers work done under Task 3, Task 4, Task 5, and Task 
7. Section 4,0 discusses robotic control techniques (Task 6). Section 

5.0 presents a short discussion of future use of the robotic simulation in 
support of the Remote Orbital Servicing System (ROSS). Section 6.0 
provides conclusions and recommendations for further work. Sections 1.0 
through 6.0 make up Volume I of the Final Report. 

Appendix A contains descriptions of the software routines developed under 
this contract and is contained in Volume II, Part I, of the Final Report. 
Appendices B through E are contained in Volume II, Part 2, of the Final 
Report. Appendix B contains the derivation of the dynamic equations for 
the force/torque requirements analysis tool. Appendix C contains the 
derivation of the simulation tool nonlinear and linear dynamics equa- 
tions. Appendix D contains the derivation of the coordinated rate control 
algorithm. Appendix E contains a discussion of simulation methodologies. 

It should be noted that the results of the work performed under Task 8 
were previously submitted as a separate report, "Remote Orbital Servicing 
System (ROSS) Final Report," MCR-82-533, dated April, 1982. 
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2.0 


DECISION-AIDING TECHNIQUES 


Artificial intelligence (AI) is the branch of computer science con- 
cerned with developing programs that perform functions people consider 
intelligent. These include interacting with people in a manner natural 
to them, adapting to changing environments, driving automated systems, 
and assisting in the process of making complex decisions. The last of 
these has become especially important because of the computer's extra- 
ordinary ability to process large volumes of information. As the tech- 
nological state of the art progresses, computers are being relied on 
more and more heavily to assist in decisionmaking. In these roles, 
computer systems must "understand" global situations, explore hypothe- 
tical alternatives, and adjust priorities as situations warrant. 

There are several domains where it has become necessary for computers 
to play a more active role in decisionmaking. One such area is in tac- 
tical decision aids. In this environment, the U.S. and its NATO allies 
are faced with unfavorable force structure ratios compared to the War- 
saw Pact countries. The U.S. depends heavily on superior tactical com- 
mand, control, communication, and intelligence (C^I) systems to 
counter the extensive quantitative lead of its potential adversaries. 
Decision aids in the C^I environment must do more than just collect, 
process, and display data. They must begin to perform many decision- 
making functions because of extremely high data rates and the need for 
nearly instantaneous reaction in the C^I environment. 

Another area in which computers must become reliable decision makers is 
in applications of autonomy, such as automated weapons systems and 
deep-space probes. Future unmanned weapon systems cannot afford to 
rely on teleoperator control due to the many issues accompanying sur- 
vivability. Therefore, it is Important to understand the automation 
requirements of such systems. Automated weapons systems must navigate, 
recognize potential threats from a deceptive adversary, and recognize 
friendly situations. Making these kinds of decisions requires an in- 
telligent decision maker. Deep-space probes must also be autonomous. 

As they travel further from the Earth, they must be increasingly self- 
sufficient because monitors on the Earth can no longer react to unknown 
situations in a time-critical manner due to the communication delay 
involved . 

As the complexity of functions such as these escalates, traditional 
algorithmic approaches to software systems become inadequate. In some 
cases this results from inefficiency and in some from the difficulty of 
specifying an explicit algorithm, as for example in the case of threat 
assessment or the medical diagnosis of disease. 

AI has evolved to fill this gap. Many of its techniques capture fuzzy 
nonalgorithmic reasoning processes and, more importantly, heuristic 
reasoning principles for decision making and problem solving that can 
be used to address situations not anticipated in the original design of 
a system. AI's action- or goal-oriented approaches allow a higher 
level of control, which greatly enhances efficiency and permits a more 
ready coordination of subtasks en route to the desired goal. AI's use 
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of natural languages such as English significantly eases user interac- 
tion and certain of its techniques can be used to reduce system devel- 
opment time. 

One important AI approach that critically depends on decisionmaking is 
the expert system. An expert system is a computer program designed to 
perform an intelligent task normally done by a human expert — for exam- 
ple, to assess tactical threat situations, diagnose medical diseases, 
isolate faults during satellite or computer system failures, or control 
an automated system. Expert systems generally contain an inference 
mechanism that drives the actual decisionmaking process and hence coor- 
dinates the actions of the expert system and the processes the expert 
system directs. Because inference engines base their decisionmaking on 
their knowledge of the world, how that knowledge is represented is 
critical. Representation is, in fact, one of the prime factors in the 
speed, sophistlcatioti, adaptability, and complexity of the inference 
mechanism, which, in turn, crucially determine the power and range of 
the entire expert system. 

Decisionmaking systems should ideally incorporate a computationally 
simple, yet powerful, technique. This is not always possible, of 
course, and speed (reaction time) is generally inversely proportional 
to complexity. Systems must thus be appropriately situated on the 
speed-complexity continuum weighing the tradeoff in accord with the 
system's application. Adaptability — the ability to deal with unantici- 
pated situations — becomes increasingly necessary as the autonomy of an 
application increases. While speed, reaction time, and adaptability 
are measures of a system's behavior, sophistication is in part a meas- 
ure of the robustness of a system's representation. 

The degree of robustness often has a direct effect on system behavior. 
Two kinds of sophistication must be considered when evaluating a repre- 
sentation. The first is level of abstraction. For example, represent- 
ing an electronic device as an organized set of functional circuits 
with functions describing input and output relationships is a higher 
level of abstraction than representing the device as a conglomeration 
of integrated circuits, resistors, etc. If the higher abstraction 
level is appropriate for analysis, being forced by a formalism to use 
the lower level is both slow and cumbersome. Often it is effective to 
be able to represent an application at multiple levels and to facili- 
tate switching between levels in the course of problem solution. The 
second type of sophistication involves another form of multiple lev- 
els. In this, a mechanism is provided that supports a hierarchy of 
representations. The lowest level contains the application representa- 
tion; the next level contains a representation of the first level's 
organization. This is often called a metarepresentation. Any number 
of levels of metarepresentation can be present in the hierarchy. This 
type of structure can be critical if a system must consider its actions 
before it performs them. 

This chapter discusses a variety of decisionmaking techniques and tools 
that have been identified and evaluated by the AI group at Martin Mari- 
etta Denver Aerospace during the last year as part of the ROBSIM proj- 
ect. Emphasis was placed on Identifying those techniques developed in 
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the field of artificial intelligence that could be applied to the 
aerospace environment. 


2.1 DECISION TREE MANIPULATORS 


The first of these techniques is the decision tree manipulator. A de- 
cision tree is a tree data structure frequently used in gaming situa- 
tions where the nodes are possible world states and the arcs are opera- 
tions that cause the world states to change. If, for example, the 
domain were the game of tic-tac-toe, a world state represented by a 
node would be the configuration of the board after a given number of 
moves. The operations represented as the arcs branching from such a 
node would be the possible moves available to the player at that point 
in the game. Associated with each node is an evaluation function that 
determines the relative desirability of the given world state. (These 
evaluation functions are generally derived empirically for a given 
application. ) A system simulates possible actions by generating sever- 
al levels of a tree in accord with its knowledge of the domain. 

Thus, from the start node of a tic-tac-toe application, the system 
would generate nine nodes or world states corresponding to the nine 
possible opening moves. For the next or third level, it would generate 
eight nodes for each of the nine nodes at the second level, since the 
second player must choose among eight moves. This third level there- 
fore has 72 nodes, corresponding to the 72 possible board configura- 
tions or world states that are possible at the end of two moves. After 
generating several such levels, the system would choose the best path 
or arc based on the result of the evaluation function. This method of 
tree search is highly dynamic — branches of the tree are not generated 
until it is time to search them. 

Obviously, both the world model and the relative desirability of a 
state depend on the domain. Given that both of these problems are 
solved, decision trees sometimes provide an effective method of making 
decisions. They can be made to be highly sophisticated: a game tree, 

one type of decision tree, can represent all possible sequences moves 
and end states of a simple game. The tree, however, becomes massive. 

For example, the size of a full game tree for tic-tac-toe can be rough- 
ly estimated by noting, as described above, that the start node has 9 
daughters, each of which has 8, etc. Thus the bottom of the tree has 
9! or 362,880 nodes. The total number of nodes in the tree is 9!/l! + 9l/2t 
+ ... + 9!/9! or 623,530. Of course, many paths in the tree termi- 
nate in end-states at a level shallower than 9 so the actual number 
will be somewhat less — but it will still be enormous and the tree would 
be computationally intractable. 

The ability of decision trees to address complex applications is hin- 
dered by a lack of both types of sophistication discussed above. This 
contributes to the computational complexity of the decision tree manip- 
ulation algorithm and, consequently, a slow reaction time. A simple 
algorithmic approach to tree manipulators is clearly insufficient: 
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manipulators must include the ability to incorporate domain-specific 
information and heuristics as well as tree pruning heuristics such as 
alpha-beta pruning (Ref 1). The latter is used during the dynamic gen- 
eration and search of the tree, as described above. It is a technique 
that determines when it is unnecessary to search entire subsections of 
a tree and therefore saves the system the expense of generating them. 

The savings such techniques bring, however, will only partially miti- 
gate the above problems with decision trees. In any case, decision 
trees tend to be unadaptable to changes in the environment that could 
not be foreseen — to, as it were, branches in the tree that could not be 
generated a priori. Finally, it is difficult to display decision trees 
and hence to understand their dynamic behavior. Therefore, special 
graphics routines must be developed to display trees and to move this 
display up and down through different subtrees. 


2.2 PROBLEM SOLVERS 


A second class of decisionmaking systems is the first-order predicate 
calculus theorem provers. In this deductive method, world knowledge is 
represented as a set of axioms and theorems. The system makes deci- 
sions by proving new theorems. To decide whether a particular goal; 
e.g., "Move box u to place p," were possible, it would represent the 
goal as a well-formed formula (wff) in the predicate calculus: 

0u) [Box(u) AND AT(u,p)]. (Ref 2) 

This is considered to be a theorem, and the system attempts to find a 
proof for it from the axioms and theorems already in the system. 

The technique generally used to construct proofs is called resolution 
(Ref 3). The basic idea behind resolution is to add to the data base 
the negation of the conclusion of the theorem to be proved and then 
attempt to find a contradiction in the data base. This is a general 
technique and has serious drawbacks. For example, to perform resolu- 
tion, all axioms and theorems must be in clause form. In clause form, 
formulas must appear as a set of clauses connected by "AND" operators, 
as in the above example. A clause is a formula with constants, vari- 
ables, or predicates connected by "OR" operators. 

While the translation of arbitrary well-formed formulas to clause form 
is relatively straightforward, it obscures the meaning of the original 
formula, making reconstruction and explanation difficult. Also, as the 
number of clauses in the data base grows, it becomes increasingly dif- 
ficult to find the correct clauses to resolve in constructing a proof. 
The search technique used by these theorem provers for finding such 
clauses is guided by general and not particularly effective heuristics, 
such as "Only resolve an axiom with a theorem — don't resolve it with 
another axiom." 
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Several systems have been implemented based solely on theorem prov- 
ing — including both problem-solving and question-answering programs 
(Ref 4), but they are highly inefficient. Again this inefficiency can 
be attributed, in part, to this technique's lack of either type of 
sophistication. Clearly, when search in these systems is not con- 
strained, the combinatorial explosion renders them inappropriate for 
most applications. One method of limiting search is to incorporate 
domain-specific information. Unfortunately, theorem provers by them- 
selves have no mechanism for doing this: they only manipulate symbols 

syntactically. They do not consider the semantics or meaning of 3 in 
expression. In fact, a general theorem prover is often used as the 
primary deductive component of a larger problem-solving system. 
Domain-specific meanings can be included by, for example, integrating 
planning techniques such as the means-ends analysis of the General 
Problem Solver (Ref 5) and STRIPS (Ref 6). In fact, SHAKEY, one of the 
early A1 experiments in robotic control, used just that combination 
(Ref 7). 

Such problem-solving systems generally define a set of states the model 
of the world can be in and a set of operators that change the world 
model from one state to another. They begin their analysis at the goal 
state, working backwards to identify a sequence of actions (i.e., oper- 
ators) that could get to the final state from the initial state. 

Means-ends analysis determines the difference between the initial and 
goal states and picks the operator that would most reduce that differ- 
ence. If this operator can be applied in the initial state, it is. If 
the result is the goal state, the search is over; otherwise the differ- 
ence between this new state and the goal state is found, a new operator 
is chosen, and the process continues. 

If the original operator can't be used in the initial state, the pre- 
conditions of that operator are set as a subgoal. The search process 
is used recursively in an attempt to find an operator that achieves the 
subgoal. If this succeeds, the original operator is then applicable 
and the search continues as above. If the subgoal is unattainable, 
another operator is found to reduce the difference between the initial 
and goal states and the process iterates. 

Another primary mechanism for circumscribing search is backtracking. 
Here an operator is chosen that, if applied, would attain the goal. If 
it can be used in the initial state, it is, and the search is com- 
plete. If not, its preconditions are established as a subgoal and the 
process is used recursively in an attempt to attain the subgoal. This 
continues until either a sequence of operators is found that, when 
applied in the initial state, leads to the goal, or a state is reached 
such that no operator, when applied, would result In that state. In 
the former case, the search is finished; in the latter, the search 
"backs up" to the state just preceding the blocked state (i.e., to the 
most recent choice point) , a different operator is chosen, and the 
search continues in this "depth-first" or "chronological" fashion. 

Basic search strategies such as means-ends analysis or backtracking can 
be augmented in a number of ways. Backtracking, for example, can be 
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not simply to the most recent choice point, but to the one that has 
been identified as the reason (or one of several possible reasons) for 
failure. In addition to this "relevant" (or "dependency-directed" or 
"nonchronological" ) backtracking, means-ends analysis can be organized 
hierarchically so as to focus initially on only the most important as- 
pects of a situation, leaving the lengthy elaboration of details until 
after a full, high-level plan has been formed. Numerous other tech- 
niques such as plan repair, constraint satisfaction, and goal regres- 
sion can be incorporated to enhance the efficiency of the procedures 
that guide search in a problem-solving system (Ref 8). The reason for 
increased efficiency of some of these is partially due to "level of 
abstraction" sophistication. If appears, however, that no meta-repre- 
sentation sophistication is present in any of these techniques. 


2.3 RULE-BASED SYSTEMS 


Another decisionmaking mechanism developed within artificial intelli- 
gence is the rule-based system. A rule-based system consists of a 
long-term memory, a short-term memory, and a rule Interpreter. Long- 
term memory contains rules, short-term memory contains Information de- 
fining the current state of the world, and the interpreter systemati- 
cally applies the rules to the world state. Rules are situation-action 
pairs: the left side of a rule contains a set of predicates in con- 

junctive normal form and the right side of a rule contains a sequence 
of actions. In conjunctive normal form, an expression is written as 
the conjunction of a set of disjunctions of literals, e.g., 

[R(x) OR T(y,z)] AND P(y) AND [-P(z) OR T(x,z)]. 

A rule resembles an if-then statement: If the left-hand side of a rule 

holds true, then the actions on the right-hand side are performed. A 
rule might say, for example. 

If Satellite downlink is off nominal rate. 

Then Advise "Re-tune bit synchronizer center frequency," and examine 
rules for satellite-redundant crystal oscillator. 

The rule interpreter searches the predicates on the left-hand sides of 
rules in long-term memory for a match with some of the "state-of-the- 
world" predicates in short-term memory. It finds all the rules whose 
predicates all match, i.e., all the rules that accurately describe some 
aspect of the current world state. The interpreter uses a conflict 
resolution mechanism to determine which of these rules is most appro- 
priate and then executes the sequence of actions on the. right-hand side 
of that rule. These actions normally modify short-term memory — i.e., 
change the state of the world — and perform I/O operations. However, in 
some rule-based systems, the actions can also modify the rules them- 
selves, giving these systems significant potential for adaptability. 
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As applications become complex, requiring more sophisticated distinc- 
tions of subtlety, the number of rules may become extremely large and 
searches of the rule base computationally expensive. To circumvent 
this problem, many rule-based systems allow for meta-rules, i.e. , rules 
defining the way rules should be searched and applied. The rule base 
or long-term memory might be partitioned into sets of related rules 
such that any given set would be relevant only in particular situa- 
tions. When such a situation is identified — i.e., when the predicates 
on the left-hand side of some meta-rule are all found to match or be 
true in the current world state — the meta-rule would direct the rule 
interpreter to confine its search to the appropriate set of rules. One 
use of this partitioning is to organize different levels of representa- 
tional abstraction. Thus, both types of sophistication are provided 
for to varying degrees in different rule-based systems. 

A prime feature of these partitioning systems is a high degree of modu- 
larity and extensibility: isolable partitions into which rules are 

grouped can readily be added to or transported between systems. Rule- 
based systems generally have numerous other unique features that can be 
advantageous for certain applications. These include significant 
sophistication and adaptability, ease of rule modifications, a natural 
parallel to the way human beings often make decisions, an ability to 
incorporate judgment into making decisions, a high degree of efficiency 
when rules are carefully organized, and the ability to trace the deci- 
sionmaking process and present it to the human user as part of an ex- 
planatory justification. 


2.4 LOGIC PROGRAMMING LANGUAGES 


In addition to specific techniques, several tools of varying generality 
have been developed. One such Inferenclng tool for computer decision- 
making is a Logic Programming Language (LPL) such as PROLOG (Ref 9) or 
LOGLISP (Ref 10). These languages support a technique of programming 
that is radically different from traditional programming languages. 
Computational specifications in an LPL consist of a set of declarative 
sentences that the system attempts to show are true. Thus, the control 
structure of a program is handled entirely by the LPL run-time support 
system. More specifically, the run-time system, in the process of exe- 
cuting a program, searches a knowledge base attempting to demonstrate 
the truth of statements in the program. Statements comprise both the 
program and the knowledge base. Statements in the knowledge base are 
referred to as assertions, and statements in the program are called 
conditionals. All statements have the same form: 

a : -b,c,d 

and can be read declaratively as "a is true if b and c and d are true" 
or procedurally as "to get a, successfully execute b, c, and d." An 
LPL acts, in effect, as a theorem prover on individual program state- 
ments. Unlike a theorem prover acting at a global level, however, an 
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LPL's resolution of a program statement can affect any number of deci- 
sion-related consequences — from the simple branching of control to the 
execution of an action or even the alteration of the knowledge base or 
inferencing strategy. Because decisionmaking includes a complex form 
of knowledge base querying, an LPL is also ideal for knowledge base 
manipulation. Since facts in the knowledge base are stored in the 
knowledge base, LPLs allow for both "level of abstraction" and meta- 
representation sophistication. The latter, however, is not encouraged 
in the LPL style of programming. 


2.5 REPRESENTATION LANGUAGE LANGUAGES 


An extremely useful tool for decisionmaking is a representation lan- 
guage language (RLL) such as the Modifiable Representation System (MRS) 
(Ref 11). An RLL is actually a union of the representation formalisms 
of a knowledge representation system and the inference mechanisms of a 
decisionmaking system. The knowledge representation aspect of RLLs 
gives them sensitivity to the kind of information being manipulated. 
Different kinds of knowledge are best represented in different ways. 
Certain procedural information, for example, might best be captured in 
a production rule format. Declarative knowledge about the attributes 
of particular items, e.g., connectivity relations among components of 
an integrated circuit, might most effectively be stored on the property 
list of the Individual components or in an associative network. Asso- 
ciating attribute information so closely with the items themselves 
might increase efficiency of computations involving such information. 
Information about sets of objects, on the other hand, might be repre- 
sented in bit vectors for optimum storage and perhaps computational 
efficiency. 

An RLL has the ability to use different representational modes for dif- 
ferent kinds of knowledge — all within the same program. This can be 
done, if desired, at a level independent of any user program. Programs 
can thus treat different kinds of knowledge in a uniform way. The 
RLL's inference mechanisms determine what kind of knowledge is being 
manipulated, accessed, or stored, and on that basis decide which means 
of representation is most appropriate for the particular Instance. 
Consequently, the structure of the knowledge base — or even the knowl- 
edge base in toto — can readily be changed without requiring modifica- 
tion of any user program. 

Sensitivity to the external environment is also an important metric for 
decisionmaking systems. Some RLLs have a unique approach to external 
sensitivity. Because these systems are designed to allow different 
types of knowledge to be represented differently, when they are asked 
to store and retrieve knowledge, they must first determine how to do 
so. This approach is generalized in such a way that before an RLL per- 
forms an operation, it determines how this operation should be carried 
out. Thus, the system inspects its knowledge base, performs inference, 
or examines the external environment to determine how to do an opera- 
tion. The last of these affords RLLs an extraordinary sensitivity to 
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the external environment, assuming it has access to the appropriate 
sensors. As a simple example, suppose an RLL is asked to do X and the 
RLL "knows" two ways to accomplish X. The first is memory efficient 
and computationally expensive. The second is memory expensive and com- 
putationally efficient. The RLL can determine the amount of free mem- 
ory and decide accordingly which method to use. Constraints in the 
external environment can affect an RLL's behavior in the same fashion. 

Besides integrating representation and decisionmaking in a single sys- 
tem, an RLL goes beyond other AI tools in another way: it provides a 

meta-representation level in which its own structure is expressed. The 
meta-representation exploits the same formalism as the first level rep- 
resentation. RLLs not only provide meta-representation sophistication 
but encourages its use. They also provide for "level of abstraction" 
sophistication in a straightforward fashion. 

An RLL can thus manipulate a representation of itself in the same way 
it manipulates user-defined representations. This allows RLLs to rea- 
son about themselves and even to modify their organization and infer- 
ence strategies. To elaborate an earlier example, an RLL might have, 
in its representation of itself, explicit knowledge about the methods 
of computation and storage it could use and the differential memory and 
computational efficiencies of those methods. It might monitor the gen- 
eral system load to identify the long-term use trend, and on the basis 
of this use assessment, the RLL could decide in general what operation- 
al and representational methods would be best. It could use that deci- 
sion in future situations and could even restructure its current knowl- 
edge base and its existing computational procedures accordingly. This 
capacity for learning is a prime feature of RLLs. It gives them enor- 
mous potential for sophistication and adaptability. 


2.6 DEVELOPMENT TOOLS 


Finally, several specific tools have been created to assist development 
of rule-based expert systems, a widespread form of AI decisionmaking 
tool. ROSIE (Ref 12), AGE (Ref 13), and EMYCIN (Ref 14) present rela- 
tively "user-friendly" frameworks for expert system development includ- 
ing facilities of varying elaboration for such things as documenting 
and responding to user requests for justification or explanation. 0PS5 
(Ref 15) is a substantially more limited tool with certain structural 
problems (such as not allowing the evaluation of functions on the 
left-hand side of rules) and few or none of the frills for such things 
as explanation. AMORD (Ref 16), a rule-based system for problem solv- 
ing, is one of the only to treat seriously the problems of how adding 
new Information or rules affects the system's consistency. 

Each of these development tools was designed for different purposes and 
hence addresses different issues and problems. Of all of them, ROSIE 
is perhaps the most flexible and powerful, permitting the user to modi- 
fy many major components of the system to suit his needs — for example, 
to design his own control structure or rule interpreter but not, it 
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should be noted, to alter the way rules and knowledge are represented. 
Much of its flexibility is due to the authors' attempts to include a 
limited form of meta-representation sophistication and a very general 
"level of abstraction" sophistication. The former is realized by col- 
locating the rule set and the knowledge base. This allows rules to 
operate on other rules as though they were data. 

Yet even ROSIE is limited, allowing only rule-based techniques. A 
mature expert system for robotic control must consist of many compon- 
ents — it might, for example, have a rule-based reasoner to establish 
what needs to be done, a planner or problem solver to determine how to 
do it, a component for extracing information from the human expert to 
construct the rule base, a component to maintain the consistency of the 
rule base and the knowledge base, as well as a natural language inter- 
face to communicate with the human users and developers. 

This is not to say, of course, that these specific rule-based develop- 
ment tools could not be used to create systems to perform a wide vari- 
ety of tasks — after all, the simplest Turing machine is sufficient for 
any computable task. The problems, however, are along the lines of 
efficiency (both computational and representational), flexibility, mod- 
ifiability, and ease of use. A given application may require any num- 
ber of control structures, Inferencing and representational techniques, 
and modes of user interaction. 


2.7 THE EXPERT SYSTEM- EXPERT SYSTEM 

A truly useful development tool would aid in the creation of all these 
facets. Such a tool would be an expert system for building expert sys- 
tems — as it were, an "expert system-expert system" or (ES)^. The 
Artificial Intelligence group at Martin Marietta has been investigating 
(ES)2 for some time. A primary constituent of this tool will be the 
Interface component that will help establish the optimal configuration 
of natural language (e.g., English), graphics, and special-purpose re- 
stricted languages (e.g. , for limited data base query or command and 
control) for system development as well as user interaction. The nat- 
ural language interface is an especially important aspect of this: it 

allows a user to communicate in near-English with a computer program — 
to give commands and requests, ask questions, and receive justifica- 
tions and explanations. This ability is essential for the widespread 
use of expert systems. 

Given that there is no sufficently-encompasslng theory of grammar and 
language, current natural language interfaces are developed as special- 
ly designed programs for particular applications. Thus, in addition to 
establishing the configuration for interaction, the Interface component 
of (ES)2 will be expert at building natural language Interfaces. It 
will combine its linguistic knowledge with considerations of not only 
the intended use and users of a system but also the domain-specific 
constraints and the contents of the knowledge base. It will have a 
similar capacity for developing graphics aids for the interface and for 
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incorporating special-purpose restricted languages to handle those 
interactions for which a highly-limited set of options is possible. 

One of the most important aspects of (ES)^ involves the transfer of 
expertise from human experts to a computer knowledge base. This has 
traditionally been a multistep, iterative process in which the AI re- 
searcher extracts knowledge from an expert, encodes it in inferencing 
rules, and tests the expert system with those rules. He then takes the 
output back to the expert who determines which parts of the output are 
incorrect and is then coerced by the researcher to identify and correct 
inaccurate rules. The researcher returns to his program with the new 
set of rules, obtains new output, and the lengthy process iterates. 

The knowledge transfer component (KTC) of (ES)2 will help automate 
and simplify this convergence to an accurate rule base. Knowing the 
domain and general intent of the application, it will, in English, 
interactively obtain information from the expert. This Information 
will be examined for inconsistencies; if any are found, the expert will 
be consulted for emendations. The knowledge transfer component will 
integrate the information into its evolving model of the expert system 
under development. This will be used to determine the logical com- 
pleteness of the information: again, the human expert will be con- 

sulted when incompleteness is uncovered. The model will also provide a 
basis for the KTC to present scenarios for which the expert describes 
the appropriate response or output. 

The KTC may also incorporate the traditional iterative process, trans- 
lating the knowledge into a form for Inferencing (e.g., into standard 
situation-action rules), running the developing expert system, and 
presenting the output and its inaccuracies to the human expert. Once 
the expert has identified the inappropriate or incorrect portions of 
the output, the KTC can examine the reasoning of the expert system to 
pinpoint the rules at fault. The process then iterates as the KTC re- 
turns to the expert and requests corrections to those rules, i.e., to 
those parts of the information supplied by the expert earlier. Using 
such techniques as consistency, completeness, and iteration in a user- 
friendly, English-based interactive environment, will enable the auto- 
mated transfer of knowledge from the human expert to the knowledge base 
of an expert system. 

Another constituent of our "expert system-expert system" will handle 
structuring and coordinating the knowledge base and inference engine. 

As noted above, different representational schemes are appropriate for 
different applications and different inferencing techniques and compu- 
tational procedures prove more effective under different circumstanc- 
es. This component of (ES)^ will choose among the varied combina- 
tions of representation. Inference and control mechanisms, determining 
the configuration most suited for the specific application, or for spe- 
cific aspects of an application. It will also embody techniques to 
adapt and extend existing knowledge bases at any point in their devel- 
opment and use. 

In a similar way, different aspects of a problem might be solved more 
effectively via different problem-solving techniques and different con- 
trol mechanisms. In the example mentioned earlier, determining what to 
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do might be best decided by a rule-based system while deciding exactly 
how to accomplish it might be handled most effectively by a planner. 
Thus, another component of (ES)^ will be responsible for decomposing 
the problem tasks and determining the most effective means of handling 
each aspect. 

The systems developed by (ES)2 will flexibly support any number and 
any combination of representational, computational, inferencing, and 
problem-solving techniques. An excellent vehicle for doing this is a 
representation language language (RLL). An RLL's capacity for choosing 
among these varied techniques, depending on the nature of the informa- 
tion or task, would allow the user to treat not only all data but also 
all tasks in a uniform manner, without concern for how the data will be 
manipulated or the task carried out. 

(ES)^ has been the long-range goal of the Martin Marietta Artificial 
Intelligence group since its inception. A crucial factor in creating 
and maintaining the flexibility of (ES)2 is the identification and 
development of new technologies. Towards this end, the AI group has 
established a replete tool base of AI technology, which it is extending 
by actively investigating and evaluating research being conducted by 
other members of the AI community. The group is further extending the 
tool base by pursuing its own primary and applied research toward the 
ultimate goal of creating and using (ES)^^ the expert system for 
building expert systems. 
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3.0 


ROBOTIC SIMULATION 


The development of robotic technology and operational systems In the 
near future will require the aid of a number of computer aided tools. 
These tools are necessary to pursue research In key technology areas, 
demonstrate concept feasibility, aid in system design, and provide an 
operations analysis capability. One of the major goals of this 
contract was to define the overall structure of a robotic simulation 
tool and to develop a framework for that tool. 

The Robotics Simulation (ROBSIM) Program has been designed to provide a 
wide range of computer capabilities in the areas of robotic system 
design and analysis. Under this phase of development, implementation 
has been in the form of building a framework for the overall ROBSIM 
program and a framework for the simulation tool within the ROBSIM 
program. These frameworks provide a base upon which to build and 
integrate robotics capabilities in a structured and coordinated 
manner. Addition of capabilities and models is made easy by the 
modular framework developed. This design allows a collection of 
capabilities to be built up as needed and will in time result in a 
powerful set of design and analysis tools. The ROBSIM program is 
expected to be a continually-evolving and expanding set of capabilities. 

The overall ROBSIM program structure is composed of three major 
functions controlled by a program executive as shown in Figure 3-1. 

The three major ROBSIM functions are; 

1) System Definition 

2) Analysis Tools 

3) Post Processing 

Each of the major functions is designed in a modular fashion to allow 
for easy future expansion. 

The System Definition function handles user input of the robotics 
system geometry and mass properties as well as environmental parameters 
and geometry. A disk file is created to be used as input to the 
Analysis Tools and Post Processing functions. The Analysis Tools 
function handles the computational requirements of the ROBSIM program. 
The Post Processing function allows for more detailed study of the 
results of the Analysis Tools function execution( s) . Each of these 
areas is discussed more fully in the following sections. 
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Figure 3-1 ROBSIM Top-Level Structure 
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3.1 


SYSTEM DEFINITION 


The system definition portion of the program operates in an interactive 
mode and allows the user to define a robotic configuration for 
analysis. This definition includes specification of the manipulator 
geometry and mass properties, environmental parameters, and graphics 
representations for the manipulator and the environment. The types of 
Joint configurations that may be specified include hinge (Fig. 3-2), 
swivel (Fig. 3-3), and sliding (Fig. 3-4). With these three basic 
joint types, it is possible to specify a large variety of manipulator 
arm configurations. 



Figiace 3-2 Typical Hinge Joint 
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Figure 3-2 Typical Swivel Joint 



Figure 3-4 Typical Sliding Joint 
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Along with the type of joint, the operator must specify the orientation 
of the joint with respect to the Individual manipulator links. The 
links are defined by their physical dimensions and mass properties. 

The mass properties include the total mass, the location of the center 
of gravity (eg), and the inertia matrix. In the current Implementation 
of ROBSIM, joint mass properties are not separated from the link mass 
properties but may be accounted for by considering the joint to be a 
part of its associated link. For example, if joint 2 of a manipulator 
had a mass of 4 kg and link 2 a mass of 10 kg, then the joint mass 
could be accounted for by inputting a link mass of 14 kg. The eg 
location would be the weighted average of the joint and link cgs, and 
the inertia matrix would be the sum of the joint and link inertia 
matrices taken from the same coordinate system (see Appendix B for a 
discussion of transforming inertia matrices). 

A graphics display package was designed and is connected to the system 
definition module so that the operator can observe the system as it is 
being defined. This allows the operator to gain a physical 
understanding of the system and helps to identify potential problem 
areas early in the development process. If the operator is not 
satisfied with the defined system, any of the input parameters may be 
interactively modified. Figures 3-5a through 3-5e illustrate the 
graphics display during the definition of a PUMA 600 manipulator arm. 

The level of detail by which the manipulator is represented can vary as 
a function of the phase of design. For example, during initial concept 
definition, the detailed physical dimension of the links is unknown, 
and approximations must be used. The system definition program 
contains an option whereby any link can be defined by simple 
cylindrical elements. The diameter and length of the cylindrical 
elements are defined by the operator. Figure 3-6a illustrates a 
simplified graphic display of the Martin Marietta SMA manipulator shown 
in Figure 3-6b. 

The output of the system definition package is a file that contains a 
description of the robotic system that can be used as input by the 
various analysis tools. This file may be archived so that a number of 
different analyses may be performed on the same manipulator 
configuration. 
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Figure 3-5 Graphios Representation of PUMA - 800 Manipuiator 






a Simple Representation 



b Detailed Representation 
Figure S-6 

Simplified and Detailed Graphics Representations 
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3.2 


ANALYSIS TOOL SET 


The analysis tool set has been separated (Fig. 3-7) into a library of 
tools that may be used for a variety of studies on the manipulator arm 
defined during system definition. Among the tools that will be in the 
library are a force/torque requirements analysis tool, a time-domain 
dynamic simulation, a frequency-domain simulation, and an 
operating-envelope analysis tool. 


ROBSIM Analysis Tool Function 


Menu-Driven Selection 
of Capabilities 


1 

Force/Torque 

1 

Time- Domain 

Frequency-Domain 

1 

Operating 

•• 1 

Future 

Requirements 

Simulation 

Simulation 

Envelope 

Expansion 

Analysis 

Tool 

Tool 

Analysis 


Tool 



Tool 



Figure 3-7 ROBSIM Analysis Tool Structure 


The operating-envelope analysis tool will allow an operator to observe 
the operating envelope of the manipulator through the graphics 
display. This will allow the operator to efficiently determine whether 
the manipulator configuration will be able to perform the necessary 
maneuvers in a restricted environment. For example, for spacecraft 
refurbishment, a manipulator arm must be able to reach through an 
access panel, grab a replaceable component, and extract the component 
without colliding with any part of the spacecraft. Joint configuration 
is an Important parameter in providing the necessary agility for a 
specific mission. With the envelope-analysis tool, it will be possible 
to observe the entire operating envelope for individual joints and 
combinations of joints up to the end effector. 

The frequency-domain simulation of a robotic system will enable an 
analysis of the stability of the arm about specific operating positions 
and will help in developing the control system. This tool will also 
enable a careful evaluation of singularity positions and their effects 
on the controllability of the system. The output from this tool will 
Include frequency-domain plots of the arm. 

During this phase of the contract, the major portion of the force/ 
torque requirements-analysls tool and the framework for the time-domain 
simulation were developed. These two tools are described in more 
detail in the following sections. 
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3.2,1 Force/Torque Requlrements-Analysls Tool 


The force/ torque requlrements-analysis tool is Intended to allow a 
designer to quickly Identify what the operational force and torque 
requirements for a specific system design will be. After Identifying 
an arm configuration, the system will be tasked to perform a maneuver. 
The requirements tool will then calculate the necessary forces and 
torques required to produce the maneuver and the resultant forces and 
torques acting on the joints and links. A mechanical designer may 
efficiently use this information to specify motor capabilities and 
material requirements for the joints and links, and to identify the 
effect of the motion on the control of the hosting body (l.e. , space- 
craft). A graphics package has been provided so that the operator 
may observe the motion of the arm during the analysis. All data is 
written to disk file to allow later post processing to obtain plots 
of any of the forces and torques that have occurred. Figure 3-8 
illustrates the functional flow of the force/torque requirements- 
analysls tool. 
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OJ 


Required 

Trajectory 



— Material Requirements 
— Motor Specifications 
— Joint Requirements 


Figure S-8 Functional Flow of Requirements Analysis Tool 







In the current implementation of ROBSIM, a sequence of rate profiles 
describes the manipulator trajectory. These rate profiles are 
second-order polynomial functions that describe either individual joint 
rates or end-effector rates, depending on user selection. Start and 
stop times for the profiles are also user options. 

If the user requests individual joint rate control of the model, then 
for an N-joint arm, the user must input N rate profiles. The rate 
profiles in this case describe the rate of displacement of each joint 
from reference positions. If the user requests end-effector rate 
control, then six rate profiles must be input. Each of the profiles 
determines one component of the complete end-effector angular and 
linear velocity vectors. Six profiles are necessary — three for the 
linear velocities along the x, y, and z axes, and three for the angular 
velocities around the x, y, and z axes. From the end-effector 
profiles, the rates and displacements of each joint at any given time 
can be calculated. The equation relating joint rates to end-effector 
velocity is 


V 


^2^ 

. • • 

= J 

w 


1 


where 

V = Linear velocity vector of the end effector; 
w = Angular velocity vector of the end effector; 

Rate of displacement of joint i; 

J = 6 X N Jacobian matrix. 

Given J and the desired end-effector velocities, the required joint 
rates can be found by inverting J: 






-1 

V 

4 

= J 

• • • 

w 

- 




Appendix D describes the derivation of the end-effector rate control 
equations and discusses a technique that can be used to find an 
approximate solution for that case in which J is singular. 

Any motion can be described as a sequence of short, simple motions. 
Thus, any manipulator motion can be specified by inputting a sequence 
of rate profiles. ROBSIM currently permits the user to define a 
sequence of up to 20 different rate profiles. 

Equations 3-1 to 3-6 can be used to calculate the forces and torques 
acting on a system in motion. The derivation of these equations is 
contained in Appendix B. 
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(3-1) 

(3-2) 

(3-3) 

(3-4) 

(3-5) 

(3-6) 


where 

X - a coordinate system located at joint 1; 

^ - the linear velocity of with respect to an Inertial 

coordinate system • 

w^ - the angular velocity of with respect to an Inertial 
coordinate system; 

- the angular velocity of X^ with respect to X^ ; 

= w^ - the angular acceleration of X^ with respect to an Inertial 
coordinate system ; 

a. =s. - the linear acceleration of X. with respect to an Inertial 

coordinate system ; 

h. . - 1?^ j , h. . Is the vector from X. to X. ; 

-Ij -xj -1 -3 

l=i , h. , Is the vector from X, to the eg of link 1; 

—lx —X 

- the Inertia matrix of link 1 with respect to the eg of link 1; 
m - the mass of link 1 ; 

- the reaction force acting at X^; 

- the reaction torque acting at X^ ; 

^ - gravitational acceleration ; 


3-12 



The use of a tilde over a vector has been used to denote the 3x3 
skex^- symmetric matrix of a vector cross product. That Is, if 



The Inputs to the equations are the quantities that describe the motion 
of manipulator relative joint displacements, velocities, and 
accelerations. The equations are used to recursively calculate the 
motion of each joint with respect to an Inertial coordinate system and 
then the forces and torques acting at each joint. The inputs to the 
dynamics routine are obtained by averaging the values of joint 
displacement, velocity, and acceleration provided by the control 
routine over a single time step. Any error due to averaging is minimal 
if time steps are small. 

The d3mamlcs routine has the capability of outputlng either parameter 
plots or printed output. If plots are requested, data representing the 
dynamic reactions at each joint at each time step are stored in a plot 
file. The user may then select the parameters to be plotted. Figures 
3-9 and 3-10 are examples of the types of plots that can be requested. 
Note that the parameters can be expressed in different coordinate 
systems, and several parameters may be included in the same plot. 
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JOINT ONE TORQUES 

(INERTIAL COORDINATES) 


X TORQUE 

Y TORQUE 

Z TORQUE 


B~ - 

— e 


TORQUE (KG-M*2/SEC*2) 



Figure 3-9 Joint Torque Plots in Inertial Coordinate System 
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JOINT ONE TORQUES 

(JOINT COORDINATES) 


X TORQUE 

Y TORQUE 

Z TORQUE 


0 

» 


TORQUE (KS-M*2/SEC'2) 



TIME (SECONDS) 


Figure 3-10 Joint Torque Plots in Joint Coordinate System 



If printed output of the dynamic analysis is requested, the data 
describing the system initial state are immediately written to a print 
file. The initial state data for dynamics include a description of 
joint configuration, component dimensions and mass properties, and the 
control trajectory. At each time step specified, the average values of 
joint displacement, velocity, and acceleration are written to the print 
file, as are the data describing the forces and torques acting at each 
joint. Figure 3-11 is an example of the initial state output from the 
d3mamlcs routine. These data were also used to generate the plots 
shown in Figures 3-9 and 3-10. Figure 3-12 is an example of the output 
at each time step during dynamic analysis. 

Because force and torque are vectors, each quantity consists of three 
scalars. Each scalar represents the component of force (or torque) 
along a coordinate axis. Thus, six scalars are output at each time 
step for the dynamic reactions at each joint. If the joint has n 
degrees of freedom (n<6), then n of the scalars represent actuator 
forces (or torques) that must be applied to drive the system. The 
remaining 6-n scalars represent the dynamic reactions that support the 
motion; these terms define the structural requirements at each joint. 

The force/torque requirement s-analysis tool also contains a graphics 
interface that can be used to aid in a kinematic analysis of the 
manipulator. The graphics display depicts the position of the arm 
during a predefined motion. This enables an operator to analyze the 
effect of joint constraints on the overall motion of the arm and to 
quickly identify singularity points in the arm configuration. 

The graphics package also allows the local environment around the 
manipulator to be represented by simple geometric solids. Figures 3-13 
and 3-14 illustrate the Martin Marietta SOS arm in two different 
environments. Figure 3-14 depicts the arm in a large space system 
assembly function, which recreates a physical simulation previously 
performed with the actual arm. 

Kinematic analysis of a design concept can be performed by moving the 
model within the workspace and by using the output capabilities of 
ROBSIM. Questions concerning manipulator reach and dexterity can be 
answered and the model arm modified until the kinematic requirements 
can be met. 
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DYNAMICS TEST 


number of joints in manipulator * I 

SIMULATION STARTS AT T « 0,00 

simulation STOPS AT T * 3,00000 

SIMULATION STEP SIZE IS DT s 0,50000 


JOINT/LINK initial VALUES! 

JOINT 1 IS A HINGE JOINT 


LINK DIMENSIONS 

(X,Y,Z)I 


60,00000 

0,00000 

0,00000 

Inches 




1,52400 

0,00000 

0,00000 

meters 

LOCATION OF LINK 

c,o,c. 

(X,Y,Z)| 

30,00000 

0,00000 

0,00000 

inches 




0,76200 

0,00000 

0,00000 

meters 

MASS OF LINK s 



10.00000 




thf link inertia 

matrix 

ISt 

20.00000 0.00000 

0.00000 12010,00000 

0.00000 0.00000 

0,00000 

0,00000 

12010.00000 



Figure 3-11 Sample Dynamias Output ^ Initial Condition 
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JOiNT/LiNK 1 


ANSULAR OISPLACEMtNT ■ 0.52J60 RADIANS 

30.00000 OEOHEES 


inertial location a 

.0,00000 0.00000 

0.00000 INCHES 






O.OOOOO o.ooooo 

0.00000 METERS 





CURRENT TR4N3, MATRIX a 

0,00000 l.OOOQO 

0,00000 







-0,06603 0.00000 

•0,50000 







-O.SOOOO 0.00000 

0.86603 







JOINT 

coordinates 


INERTIAL COORDINATES 


X 

Y Z 


X 


Y 

Z 

LINK VECTOR (INCHES) 

60.00000 

0,00000 0.00000 


0.00000 


-51,96152 

•30.00000 

(METERS) 

T. 52000 

0.00000 0,00000 


0,00000 


•t,319S2 

-0.76200 

REL. An6, VEL. (R/SEC) 

0.00000 

0,52360 0.00000 


0.52360 


O.OOOOO 

0.00000 

REL. ANS. ACC, (K/SECT2) 

0.00000 

0,00000 0.00000 


0.00000 


0,00000 

0.00000 

TOTAL ANG. VEL. (R/SEC) 




0,52360 


0,00000 

O.OOOOO 

TOTAL ANG. ACC. (R/SECta) 




0.00000 


0,00000 

0,00000 

total LIN. ACC. (I/SECT2) 




0.00000 


0.00000 

0.00000 

(M/SECt?) 




0,00000 


0,00000 

0.00000 

REACTION force (KG-I/SECT2) 

-02,20670 0, 

00000 0.00000 


0,00000 


71.22774 

41,12336 

(KG-M/SECt2) 

-2.08907 0. 

00000 0,00000 


0,00000 


1.60916 

1.04453 

REACTION TORQUE (KG-lt2/SECt2) 

0.00000 

-0.00012 0,00000 

•0,00012 


0.90000 

0.00000 

(KG-Mt2/8ECT2) 

0.00000 

0.00000 0.00000 


0,00000 


0,00000 

0,00000 

inertia matrix 

20,00000 

0,00000 0.00000 


12010,00000 


•0,00039 

•0.00023 


0,00000 12010,00000 0.00000 


•0.00039 


3017.50000 

•5191.82227 


0.00000 

0.00000 12010.00000 


•0.00023 


•5)91,02227 

9012,50000 

* * * 

* * 

* * 

ft 

* 

ft 

* 

a 

HANIP, TOOL LOCATION (INERTIAL 

CaO«OlNATES )1 



0.00000 


•51,96152 

•30.00000 

* * 

* <1 

* * 

ft 

• 

ft 

* 

• 

* * * 

* * 

* * 

ft 

• 

ft 

* 

• 


Figure 2-12 Sample Dyncmias Output 
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Figure S-li 

Martin Marietta SOS Manipulator in Space Structure Assembly Environment 
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3.2.2 Time-Domain Simulation Tool 


The simulation tool Is Intended to ultimately provide a realistic 
computer simulation of a manipulator composed of actual or proposed 
components. Using models of manipulator components, such as 
amplifiers, motors, power trains, etc, along with a complete system 
d3rnamlcs formulation, the simulation tool will provide a realistic 
testbed for control technique studies. Incorporation of artificial 
Intelligence technology within manipulator capabilities, and general 
study of manipulator system and component performance. Within the 
current development phase, the simulation tool structure has been 
defined and Implementation begun. The simulation tool has been 
designed using closed-loop methods and state variable formulation. 
Appendix E Is a discussion of closed-loop versus open-loop methods as 
well as a justification for using the state-variable approach. Figure 
3-15 presents a block diagram of the closed-loop method. The work 
performed within the current development phase has been restricted to 
developing a single joint model using the state-variable formulation. 
Placed within the context of Figure 3-15, all current work has been 
within the a priori block. The adaptive methods will be addressed In 
future expansion of the simulation tool capabilities. 


Disturbance System Equations 

Identification and Parameters 



Figure 3-15 Closed-loop Simulation Tool Structure 


It should be noted that the work performed under the current contract 
used a linear state variable approach to simulation modeling. The 
software structure of modular components with well-defined interfaces 
is not limited to a linear state variable application. A non-linear 
state variable approach (or any modeling approach) can be used. The 
linear state variable approach taken allowed easy modeling of the 
single joint system and easy application of the Kalman filter to that 
system. 

Implementing simulation tool capabilities within the current 
development phase has consisted of designing, coding, and testing a 
computer model of a single manipulator joint using the state-variable 
formulation. Figure 3-16 shows the basic joint model design. The 
computer model design Is modular with well-defined Interfaces between 
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blocks to allow flexibility in defining the configuration of components. Each 
block within the model uses the state-variable formulation. Figure 3-17 shows 
a typical component block diagram illustrating the state-variable approach. 

The basic equations in the state variable formulation can be written as: 


x(k+l) = (j)(k+l,k)x(k) + 0(k+l,k)u(k) + w(k) 
y(k+l) = C(k+l)x(ld-l) 

^(k+1) = H(k+l)y^(k+l) + ^(k) 

where 

u = control array 
X = state variable array 
y = observable array 
z = sensor output array 
w = process noise array 
V = sensor noise array 
4> = dynamics matrix 
0 = control matrix 
C = observability matrix 
H = measurement matrix 


(3-7) 

(3-8) 

(3-9) 


The equations that define the operation of the component must be placed 
in state variable form, i.e., Equation [3-7]. This process defines the 
control array, u, and the state-variable array, x, as well as the 
required (j> and 0 matrices. The observability matrix, C, must be 
defined in a manner that will convert the state variable array, x, to 
the actual component output array, y. Sensor modeling is handled by 
defining an appropriate H matrix to convert the component observable 
output array, y, to the sensor output array, z, as shown in Equation 
[3-9], Figure 3-l6 shows that the control array, u, is constructed 
from system observable data through the prespecified component D 
matrix. The equation representing this procedure is 

u(k) = Dy(k) 

Figure 3-16 also shows that sensor data are combined and modified 
appropriately by the M matrix to compare sensor data with the 
prespecified reference signal, r. The error resulting from this 
comparison is the input to the control box. The current computer model 
handles the computations for each component exactly, as depicted in 
Figure 3-16 using Equations [3-7] through [3-10]. 
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1. All blocks are in state-variable formulation. 

2. Configuration is flexible, i.e., it has unlimited block linkage. 

Figure 3-16 Joint Model 


















Component Model 



L 


_1 


Legend: Sensor Model 

u Control array f~ 

X State-variable array i 
y Observable array 
z Sensor output array | 

w Process noise array | 

V Sensor noise array ^ v(k) 

Figure 3-17 Typical Component Model 
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Also, a Kalman filter for the entire joint model has been Implemented. 
The Kalman filter formulation requires the development of the system of 
equations representing the entire joint model. Using Equations [3-7] 
through [3-10], the set of equations required to represent the entire 
joint model can be written as 


x^(k+l) = ,k)x^(k) 

x^(k+l) = (j)^(k+l,k)x^(k) 
x^(k+l) - <}.^(k+l,k)x^(k) 

Xp(k+1) = <j)p(k+l ,k)Xp(k) 
Xp^(k+1) = (|)p^(k+l ,k)Xp^(k) 


+ 0^(k+l,k) [r(k) + 
+ e^(k+l,k)u^(k) 

+ 0j^(k+l,k)Uj^(k) 

+ 0p(k+l,k)Up(k) 

+ 0^(k+l,k)Uj^(k) 


] + w^(k) 

+ 

+ w^(k) (3-11) 

+ Wp(k) 

+ 


y^(k+l) = C^(k+l)x^(k+l) 
y^(k+l) = C^(k+l)x^(k+l) 
y^(k+l) = C^(k+l)x^(k+l) 
yp(k+l) = Cp(k+l)Xp(k+l) 
y^(k+l) = Cj^(k+l)Xj^(k+l) 


z^(k+l) = H^(k+l)y^(k+l) + v^(k) 
z^(k+l) = H^(k+l)y^(k+l) + v^(k) 
Zp(k+1) = Hp(k+l)yp(k+l) + Vp(k) 
z^(k+l) = H^(k+l)yp^(k+l) + Vj^(k) 


(3-12) 


(3-13) 


UaO<^) = Z(k) 

Z(k) 

Up(k) = Dp 2(k) 

u^(k) = Dp ^(k) 


(3-14) 
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In matrix form, Equations [3-11] through [3-14] can be written 



(3-15) 


(3-16) 



Equation [3-15] can be rewritten as 


(3-17) 


(3-18) 



(3-19) 
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Examining only the second term in the right-hand side of Equation 
[3-19] and using Equations [3-16] and [3-18], the following equation 
can be written 



Equation [3-19] can now be written as 

2 £(k+l) = $ (kf l,k) 2 c(k) + 0 ( kf 1 , k)^( k) + w(k) (3-21) 

where 


X = [x^ X^ X^ Xp Xj^]^ 

a = [r z]^ 


W = 


[Wc w^ w^ Wp 



$ 



' e„M~ 
c (_ c 

0 I 0 
0 I 6 
0 f 0 
0 ; 0 _ 
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The system sensor equation can be written using Equations [3-16 and 
[3-17]. 


£^(k+l) = H (k+l)3c(k+l) + _v(k) 
where 

^ ■ ‘’=c ’‘a ’Si 


(3-22) 



r 


r“ -Hi 

C ' 0 


1 A 


Ci _ 


o 

o 


j 

H = 

' 0 ^ 




: «L 


° ! n 



0 


-I ''l J 


The Kalman filter equation for the system can now be written as 


x(k+l/k+l) = $(k+l,k)x(k/k) + 0(k+l,k)a(k) 

+ G(k+l)[z(k+l) - ^(k+l)$(k+l,k)x(k/k)] 


(3-23) 


where 4>, and ^ are defined for the system Equations [3-21] 

and [3-22] and 


X = the Kalman filter best estimate of the system states and the 
filter G matrix is defined by the following equations; 


P(k+l/k) = $(k+l,k)P(k/k)«I>'^(k+l,k) + Q(k) 
P(k+l/k+l) = [P(k+l/k)“^ + fl(k+l)'^R(k+l)”^ (k+1)] 

G(k+1) = P(k+l/k+l) (k+l)'^R(k+l)"^ 
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where 


0 


R(k+1) = 


'M 


Q(k) = 




W. 


P(k/k) = 


w, 




'Lj 


M 






(initially set to 
large values) 


Figure 3-18 shows the system-level block diagram for the joint model 
and Kalman filter as defined by Equations [3-21], [3-22], and [3-23]. 
The implementation of the Kalman filter in the computer model includes 
the switching logic shown in Figure 3-18. This allows the user to 
select either the joint model sensor estimate array, or the Kalman 
filter sensor estimate array, z , in the feedback loop. 
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|N> 


















The next step in developing the simulation tool will be the expansion 
of the single-joint model to a two-joint system. Problems associated 
with multiple- joint systems will be identified and addressed at the 
two-joint level before attempting to expand the model to handle an 
N-joint system. The most apparent problem associated with expanding 
from a single-joint model to a multiple-joint model is the need to 
consider the dynamics (or load block) problem on a system basis, 
instead of for individual joints. In simplified form, the multiple 
joint-model is shown in Figure 3-19. The dynamics equations required 
for the two- joint case have been developed within the state variable 
formulation. Appendix C presents the two- joint dynamics. 


Joint 1 Applied 



Figure 3-19 N Joint Model Structure 
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3.2.3 Single Joint Simulation Example 


Implementing the single-joint model and Kalman filter provided a 
computer capability using the state variable approach. The computer 
model allows demonstration of the basic concepts of component modeling 
as well as some of the state-variable formulation concepts that will be 
required to Implement the adaptive methods in future simulation tool 
enhancements . 

The discrete, state-space model that was developed in the previous 
section is illustrated in this section. A relatively simple system 
consisting of an amplifier, armature-controlled dc motor, and an 
Inertial load is used as an example. The block diagram for this system 
is shown in Figure 3-20. 



Note that this is an "analog" control system; all individual blocks and 
the feedback signal are continuous. Continuous state equations are 
easily discreted by considering the nature of the state transition 
equation. This determines how state variables transition from one time 
point to the next. The discrete state representation is formulated by 
determining a suitably small time Interval, T, and assuming that the 
inputs, u, can be considered to be constant over this Interval. 

Because T will be chosen to represent a sampling frequency above the 
Nyquist rate, the assumption on the inputs is valid. 

The discretizing process is Illustrated using the continuous system 

X = Fx + Gu (3-24) 

This has the continuous time solution, 

x(t) = e^^^”*^o^x(t^) + J e^^*^"^^Gu(T)dT ( 3 _ 25 ) 

o 
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Now, the assumption t - t^ = T leads to the discrete system 
x(n+l) = $x(n) + Tu(n) 


$ = 


FT 

e 



Gdn 


(3-26) 


The models for each block are described below. Each model Is 
"discretized" In the state- variable format described earlier. (The 
component values and appropriate constants that are used in the example 
have been chosen arbitrarily! they do not correspond to a real system. 


Amplifier - The amplifier has been modeled as a first-order system as 
shown below. 



The voltage input to the amplifier is "e^” and consists of the 
difference between the reference signal ( 0 j^) and the position feedback 
signal ( 0o)» The amplifier output voltage is "eo". 


The differential equation describing the amplifier is 

deo(t) 

+ 50Ke^(t) = 50Ke^(t) ( 

The amplifier state equations are derived using Equation [3-27]. The 
state variable is chosen as Sq (t). Therefore, 

i^(t) = -50 x^(t) + 50K u^(t) (. 

Note, however, that (t) is a function of two other variables: 0 . (t) , 
the reference input; and0^(t), the load output displacement. 
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However, the load position Is an observable variable for the load 
subsystem, This means that the amplifier Is actually a two-input, 

single-output system. This Is shown below In equation [3-29]: 

i^(t) = -50 x^(t) + [50K - 5OK][0^(t) + Y^j^(t)] 

With 


8i(t) - and - u^(£) 


Equation [3-29] takes the form of (3-7) with no noise. 

It should be noted that for all blocks In the example, the observability 
matrices, C, and the measurement matrices, H, are all set to the Identity 
matrix, I. 

DC Motor - A system diagram for the dc motor is shown below: 


R L 



Figure 3-22 DC Motor Mod^t 


The voltage equation for the motor is 

e (t) = Ri (t) + L dijjj(t) + e, (t) 

dt (3-30) 

The back-EMF voltage (eb) is a function of the armature angular velocity 
and the motor back-EMF constant (Kg). If the armature angular velocity 
is A , then the voltage equation Is (in Laplace operator notation): 

E (s) = (R + Ls)I (s) + ICs(0 (s)). 
o m 'B A 

The output torque of the motor, (Tj^) Is related to the motor current, 

(Ijj) by the torque constant, K-j-: 


T (t) = 1 (t) 

m T m 


(3-32) 
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The motor state equations are derived from equation [3-30]. The motor 
current, l^. Is an appropriate choice for a state variable. 

= -R - eb(t ) + e^(t) 

L L -T~ '' 

Note that eg (t) Is actually (t) (the observable variable for the 
amplifier), and e^ (t), as discussed earlier. Is a function of other 
system variables. 

Load - The load dynamic system Is shovm below: 



The load differential equation Is 


T (t) = Jt d^(0„(t)) + d 6o(t) 

m ^ — 

dt^ dt 

In Laplace notation 


(3-34) 


(3-35) 


The basic load equation Is [3-34]. Because this Is a second-order DE, two 
state variables are required. These are chosen as 


’‘IL ■ 


^2L ■ 


The state description for this system Is 





(3-36) 
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Digital Control Implementation - So far, the discussion has described the 
simulation of a continuous feedback system. However, any control system 
can be simulated. Because control variables are handled in a separate 
part of the program, control Inputs can be altered at any Integer multiple 
of the update rate of the continuous system. Because the control 
subroutine is separate, any control algorithm is feasible. 

Numerical Example - The values shown in Table 3-1 were used to develop a 
closed-loop transfer function. 


L = .2 B = 10 

R = 1 Kb = 1 

J = 1 Kj = 1 


Table 3-1 Values Used for Closed-Loop Transfer Function 


The resulting closed-loop transfer function is 


0j^(s) 


250K 

s^ + 65s^ + 800s^ + 250s + 250K 


(3-37) 


With a gain of K = 20, the characteristic equation becomes 


4 

s 


+ 65s^ + 800s^ 


+ 250s + 5000 = 0 


(3-38) 


The values in Table 3-1 were used in the discrete state-space model. The 
time Interval update used was 0.05 seconds. A plot of the computer model 
response for a gain of K = 20 is shown in Figure 3-24. This gain value 
was used to compare the performance of the discrete state model to the 
continuous system performance. Damped natural frequency and percent 
overshoot were used as the comparison factors. The response of the 
discrete state model for several different values of gain is shown in 
Figure 3-25. 
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Ratio to Input Command 

0.00 0.25 0.50 0.75 1.00 1.25 1.50 


o 




Figure 3-25 Joint Model Response for Gain Values of 5j lOj 15, and 20 
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Results shown in these figures were obtained from the computer 
simulation and verified by hand calculation. This simple example was 
to verify the computer model performance and the state-variable 
implementation. 

Estimation Example - In Appendix E, a thesis was presented which 
implied that modeling of a particular system was impossible if the 
classification set was not attainable. In addition, a problem was 
postulated that required solving the estimation problem to solve the 
control problem. This example will serve to clarify these notions. 

Consider the example used previously. For this example, it can be seen 
that input to the control box requires feedback from the load box 
sensor. To dramatically Illustrate the need for estimation, it was 
assumed that moderate process noise is propagated and that the 
measurement noise on the load cell is extremely high. This corresponds 
to a condition characteristic of a broken sensor or an extremely poor 
device. 

A constant value of 10.0 was the assumed reference input. The 
.objective of this demonstration is to show it is impossible to achieve 
an output equal to 10 under these noisy conditions without performing 
the estimation function. Figure 3-26 shows a time trace of the error 
resulting from the reference signal minus the sensor feedback. As 
shown, this resulting error makes it impossible to regulate the output 
of the load to approach the desired reference signal. However, by 
using the Kalman filter, the noisy feedback signal created by the poor 
sensor can be cleaned, producing a modified feedback signal, 2. This 
signal can be used to provide the feedback required to compare to the 
reference input. Implementation of this scheme results in Figure 
3-27. Comparing this figure with Figure 3-26 clearly demonstrates the 
improved performance that can be achieved by solving the estimation 
problem. 
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3.3 


POST PROCESSING 


The postprocessing package is intended to provide the ability to 
perform more detailed study on the results of analysis tools 
executions. Creation of plot files and other data files can be 
requested during the execution of any of the analysis tools. These 
files are then available for input to the various postprocessing 
capabilities. Implemented postprocessing capabilities Include the 
ability to replay the system motion graphics from the requirements 
analysis tool and the ability to produce parameter plots for requested 
data from either the requirements or simulation tools. Eventually, 
this package will be expanded so that a number of statistical tools 
will be available. Current implementation allows postprocessing on the 
results of a single analysis tool execution. Future enhancements will 
provide for the study of the results of multiple analysis tool 
executions to allow parametric studies. 
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4.0 MANIPULATOR CONTROL TECHNIQUES 


4.1 INTRODUCTION 

This section addresses the problem of manipulator system control. Task 6 
of the Statement of Work proposed definition of a set of control algo- 
rithms to drive models of the Unlmate 600 and Martin Marietta SOS man- 
ipulators. Two factors limit the feasibility of modeling these specific 
manipulators. First, complete physical and mass properties data was not 
available for either arm. Secondly, the simulation capabilities of the 
ROBSIM program are not sophisticated enough at this stage of development 
to allow simulation of these arms to any realistic level. Consideration 
of specific manipulators at this time is not required in order to proceed 
toward the goal of this contract, which is to develop a general simula- 
tion capability. 

What has been accomplished is an extensive literature survey on the topic 
of manipulator control and a general study of control techniques. 
Subsection 4.6 contains a large list of current references which are 
referred to throughout the following discussions. Implementation and 
testing of various control techniques will be carried out in the next 
phase of ROBSIM development. What follows is a general discussion of 
current manipulator control philosophy. 
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4.2 


PROBLEM DESCRIPTION 


The manipulator control problem is a composite of several individual 
problems. The primary problems of interest are introduced by con- 
sidering a generic manipulator system as shown in Figure 4-1. 



In this system two manipulators are shown performing a coordinated 
task. This immediately identified one problem of interest: 
coordinated arm control. 

There are three main problems associated with the control of a single 
manipulator. The first problem has to do with kinematics, essentially 
the geometry of the manipulator. The second problem deals with the 
dynamics of the manipulator. The last problem addresses manipulator 
performance requirements. 

4.2.1 Kinematics 


The kinematics problem arises from the fact that a manipulator task is 
generally specified in some local coordinate frame. The most natural 
frame for describing a manipulator, however, is in terms of joint 
angles. This results in a need for a means of transforming from local 
to manipulator coordinates and vice-versa. This has been addressed in 
the literature quite extensively. Deriving the basic transformation 
equations and the necessary Inverse relationships is not difficult. 

The problem lies in achieving computational efficiency. This problem 
has recently been addressed in [3] and [4]. 

4.2.2 Dynamics 


The central focus of the manipulator control problem is the Inherently 
nonlinear nature of the associated djmamic equations. These can be 
written as, [5]; 
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A(q)q + Hq + l(q,q) + Z.(q) = 

= 6x6 inertia matrix 

= 6x6 diagonal viscous friction matrix 

= 6x1 vector incorporating coriolis and 
centrifugal terms 

= 6x1 vector defining gravity terms 
= 6x1 vector of input generalized forces 
= 6x1 vector of joint positions 

The nonllnearltles represent a severe problem from the standpoint of 
control system design in that no unified methodology exists for con- 
trolling a nonlinear system. This has resulted in many control 
approaches that Incorporate a dynamic simulation model, [5]-[8], into 
the controller. This can be viewed as a form of "model-reference" 
control. The widespread need for simulation of manipulator dynamics 
has resulted in a continued interest in achieving simplified dynamic 
models [9]- [11]. 

Another Important area of Interest relating to manipulator dynamics is 
the modeling of distributed parameter effects (vibrational modes). The 
need for this type of research is recent in origin since manipulators 
have traditionally been "over-designed". The current trend is towards 
lighter weight arms with less inertia. This trend arises both from 
performance and economic requirements. Another motivation for studying 
flexible arm dynamics comes from the forecasted use of very large arms 
in space for the construction of large space structures. A summary of 
current work in this area is contained in [13], [14]. 

4.2.3 Performance Requirements 


where 

A(q^) 

H 

l(£,q.) 

P(q) 

&- 1 ] , 

5 . 


Any control system design centers on a performance requirement for the 
closed loop system. In the case of a manipulator system, however, 
there might be several different sets of requirements that govern 
performance over a period of time. To perform a typical task, e.g. , 
inserting a peg in a hole, the manipulator control system must first 
move the peg to the vicinity of the hole. This amounts to following a 
displacement-velocity (and possibly acceleration) profile for both 
position and attitude of the end-effector. To actually insert the peg, 
however, sensed force and torque information must be Included into the 
controller to account for misalignments, friction, etc. This is 
generally referred to as "compliance" based control. Task-oriented 
control has been discussed extensively in the literature [16] - [29]. 
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4.3 APPROACHES TO SERVO CONTROL 

As pointed out in the previous section the manipulator presents a 
unique challenge for control system design. This stems from the fact 
that all classical control design methods (both continuous and digital) 
assume that the plant to be controlled is a linear time-invariant 
system. An attempt to use unaltered linear approaches to the manipu- 
lator problem results in system performance that is dependent on 
manipulator configuration. Joint velocities, etc. This has led to a 
series of approaches that attempt to incorporate knowledge of the 
nonlinear d 3 mamic system into the control structure. 

4.3.1 Inverse Controllers 


The idea of the "inverse controller" has permeated the majority of 
control schemes that have been proposed in the literature [5] - [8], 
[16], [20]. The basic idea is that for a required trajectory of the 
manipulator. Equation [4-1] can be solved in reverse; l.e., given the 
desired joint values, r can be explicitly solved for. Because it is 
assumed that there is not a direct match between the model and the 
actual manipulator, additional feedback gain terms. are necessary to 
account for differences in desired and actual system states. In 
general these gain terms operate on position and velocity errors. 



The asymptotic stability of this method is demonstrated by examining 
the equations governing the error term, ( £) , shown in Figure 4-2. 
Defining e as: 

[4-2] e = q^j - q 
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The error differential equation becomes: 


[4-3] e + k^e + k^e = 0 


Since this is an ordinary differential equation, the path of e is 
totally defined by Initial conditions, e(o), and the values of kj 
and k 2 « 

This is a totally viable scheme if the exact system dynamics are known 
a priori . The problem is that, if a situation occurs in which the load 
is unknown, then Equation [4-3] is no longer valid. 

Another practical drawback to this method is the need for carrying 
along a complete dynamic simulation of the ideal, system. Because of 
the computational complexity Involved, simplifications in the dynamics 
are generally made [9]. This also results in error. 

4.3.2 Stability-Based Controllers 


Other approaches to manipulator control that differ significantly from 
those described above have viewed the problem from the standpoint of 
modern control theory [26] - [27], [30]. These methods describe 
controller stability from the standpoint of Liapunov functions. This 
is a natural approach, considering the structure of the underlying 
dynamics. 

As in the case of the Inverse controllers discussed previously, this 
approach is feasible if it is assumed that the dynamics governing the 
system are explicitly known. In the case of [30], for example, the 
system Hamiltonian must be known. When knowledge of the system 
dynamics is Imprecise the control law generated is only an approxi- 
mation to that desired. 

Other researchers have attempted to apply features from modern control 
theory to the manipulator problem. In [31] - [32] and [14], linear 
quadratic optimal control theory has been applied. In [33], results 
from multivariable control theory have been applied to the problem of 
"decoupling" the system. This implies either state variable feedback 
or a transfer matrix that turns a coupled multivariable system into a 
series of single-input, single-output systems. 

4.3.3 Adaptive Control 

The different approaches to manipulator control that have been dis- 
cussed all rely on one common assumption: complete knowledge of the 

manipulator dynamic state. While the general form of the equations is 
well known the coefficients, specifically the inertia matrix, will be 
time-varying in the general case. One approach to overcoming the 
impact of the time-variations on manipulator performance is to make the 
controller adaptive. While the term adaptive has been used loosely 
throughout various disciplines the discussion here will center on a 
specific definition; the so-called "Parameter Adaptive" controllers. 
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A parameter adaptive controller adjusts coefficients of a variable 
"filter." A general adaptive controller Is shown In Figure 4-3. 



Figure 4-3 General Adaptive Controller 

As shown In the figure, it is assumed that the plant to be controlled 
Is either initially unknown or time-varying. The parameter adaptive 
controller consists of two primary blocks: the parameter estimation 

block and the control law block. The functions of each of these is 
discussed in more detail below. 

The parameter estimation block determines using sensor data, a set of 
coefficients that adequately describe the system to be controlled. 
This definition is purposefully vague because of the wide variety of 
parameter estimation techniques that exist. A typical parameter 
estimation block is shown in Figure 4-4. 


Y 
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Figure 4-4 General Parameter Estimation 
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The parameter estimation algorithm operates on Input and output data to 
generate an estimate of the unknown parameters - S(z) and 6(z). 
Techniques for parameter estimation have been widely studied both for 
control and signal processing applications. Algorithms are available 
for deterministic and stochastic systems. 

The output of the parameter estimation block Is then used In control 
law formulation. There are many ways of doing this just as there are 
many methods for designing non-adaptlve controllers. The most general 
control form Is model- reference control. In this case the controller 
functions to make the closed-loop system match a desired transfer 
function (or matrix). A special case of this type of control Is 
"one-step ahead optimal," or, minimum-variance control. This Is 
discussed In more detail below. 
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4.4 


Predictor Model Control and Equation Error Parameter Estimation 


The adaptive controller formulation presented here was first introduced 
in a 1978 Technical Report [34], and then in the IEEE Transactions on 
Automatic Control in 1980, [35]. The 1980 paper is widely recognized 
as being the first complete proof of global stability for any adaptive 
controller. 


The adaptive controller has two functional blocks - a control law block 
that calculates the inputs to be applied to plant actuators, and a 
parameter estimation block that provides a specific set of parameters 
that are used in control law formulation. (The structure is similar to 
Figure 4-3 . ) 

The control law that is being used is referred to as a "one-step-ahead" 
or "deadbeat" algorithm. 


When the plant to be controlled can be modeled as: 


[4-4] 


Y(k+1) = a Y(k) + ...+a Y(k-n+l)+b.U(lc)+. . .+b U(k-m) 

n u m 


[4-5] 


Then a predictor type control law can be formulated. This assumes that 
the reference signal is known one step in advance, i.e., Y*(k+1) is 
known at time k. (This leads, of course, to a tracking delay of one 
sampling instant.) The actual control law is derived by setting Y(fcH) 
= Y*(k+1) in Equation [4-4] and then solving for U(k). 


U(k) 


Y* (k+1 ) -a ^ Y (k) - . . . -a^Y (k-n+1 ) -b (k- 1 ) - . . . -b^U (k-m) 


With the a's and b's known, the U(k) calculated will result in Y(k+1) = 
Y*(k+1). This same formulation can be used when there is a system 
delay of more than one, i.e., the output at k+1 is a function of inputs 
applied two or more sampling Instants in the past. It is shown in [36] 
that the same basic approach can be used to execute "model-reference" 
control. (The formulation in [4-4] and [4-5] leads to what has been 
called "inverse control", i.e., the transfer function of the closed 
loop plant is a simple delay.) This approach to control law formu- 
lation is general and flexible and does not unnecessarily constrain the 
designer. 


The general concept of parameter estimation was Introduced in the 
previous section. A specific parameter estimation algorithm, recursive 
least squares, will be discussed here. 

Recursive least squares falls into the family of the so-called 
"equation error" parameter estimation schemes. These are discussed 
extensively in [36] and [37]. The name "equation error" is derived 
from the basic structure of the estimation algorithm, (see Figure 4-5). 
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Most parameter estimation algorithms have the form: 

l4-6] 0(k+l) = 0(k) + re(k) 

In an "equation error" formulation, 

[4-7] e(k) = Y(k) - $^0(k) 
where 

= [Y(k-D ,Y(k-2) , . . . ,Y(k-n+l) ,U(k-l) , . . . ,U(k-m-l)j 

0 = [aj^ja^, . • . . . . ,b^ ] 

Equation [4-7] is essentially the same as Equation [4-4], 
except that parameter estimates are used instead of the 
actual parameters. For the true parameters, e(k) = 0. 
Hence the name "equation error", i.e., how well the 
estimated parameters satisfy Equation [4-4]. For e(k) 0, 
the parameter estimator will continue to update the 
estimate. 

F-igure 4-5 Equation Error Parameter Estimation 


The " r " term in Equation [4-6] is what differentiates parameter 
estimation schemes. In the case of recursive least squares I is chosen 
as shown below. 


[4-8] 


a(k)P (k-d-1 )(j) (k-d) 

1+a ( k) ()) (k- d ) ^ P ( k-d- 1 ) <t>(k-d ) 


P(k-d) = P(k-d-l) 


a (k)P (k-d-1) d) (k-d) t)> (k-d) '^P (k-d-1) 
l+a(k)(})(k-d)Tp(k-d-l)(j)(k-d) 


(The "d" delay is necessary to retain causality). Simpler schemes are 
available but they have very poor stochastic properties. 

Using the controller and parameter estimation algorithm described 
above, the adaptive controller functions as shown in Figure 4-6. 
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Figure 4-6 Adaptive Control Flow Diagram 
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4.5 


CONCLUSION 


This report has discusses some of the primary approaches that have been 
used in manipulator control. Adaptive control appears to be extremely 
promising in regard to projected performance since it is one method 
that compensates for parameter drift and load changes. 
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5.0 ROBSIM SUPPORT FOR ROSS 


5.1 INTRODUCTION 

One of the objectives of the Robotic Simulation Tool is to provide 
support for the design, development, and deployment of telepresence 
systems for in-space satellite servicing and maintenance. 

The design of such a system was the subject of Task 8 of the current 
contract. Remote Orbital Servicing System (ROSS). The results of Task 8 
were documented in a previous report, MCR-82-533. 

Specific technology issues must be addressed. These issues will be 
related to two segments of the system. These two segments are: 1) the 

ground segment and 2) the space segment. Elements associated with the 
ground segment are: a) the human operator, b) hardware/ software 

supporting the man at the control station, c) data processing, and d) 
mission assessment. Space segment elements will be: e) the work site 

and f) data processing. 

Technology issues which require resolution are best defined with respect 
to the elements described above. Table 5-1 defines these issues. 

Many of the issues given above can be resolved by creating a simulation 
tool representing the teleoperator and robotic system. To answer these 
concerns, the simulation must be capable of the following functions: 

1) For specific designs, it will allow system evaluation, timeline 
and task planning, operator training, and backup support during 
mission operations. 

2) Act as a design tool for evaluating various levels of automation, 
direct, and supervisory control. 

3) Allow evaluation at the system level, advances in subsystem 
technology. 

4) Allow parametric studies of subsystems and components supplying 
guidance as to high leverage areas requiring research at the 
technology base level. 

5) Allow error analysis and Investigation of error recovery and 
backup mode operations. 

6) Allow investigations of advanced control techniques including 
trajectory optimization. 

7) Allow investigations of the applications of artificial 
intelligence (AI) technology in automated decision making. 

8) Allow studies of man/ machine interface with remote systems to 
develop an educated telepresence and to enhance man's capability 
to accomplish remote operations by increasing his supervisory 
capabilities for complex systems. 
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Table 5-1 Technology Issues 


a) 

Human Operator 

o 

Acceptance of Technology 



o 

Number of Operators Required 



o 

Single Operator Time-Constrained 




Capabilities 



o 

Human Endurance 



o 

System Response Time 



o 

Perceptual Limits 



o 

Information Assimilation Rate & Capacity 



o 

Cognitive Limits 

b) 

Control Station 

o 

Delay 



o 

HW/SW Architecture 



o 

Method of Stereo Vision Display 



o 

Visual Enhancement 



o 

Display Mechanisms 



o 

Command Mechanisms 



o 

Integration of Display and Command 




Mechanisms 



0 

Communication of Task Semantics 

c) 

Data Processing 

o 

Degree of Autonomy 



o 

Servo Loop Stability 



o 

Delay 



o 

Information Bandwidth 



o 

Coordination of Multiple Effectors 



o 

Collision Avoidance 



o 

Topography Estimation 



o 

Robust Control 



o 

Mistake Monitoring 

d) 

Mission Assessment 

o 

Task Plan Definition 



o 

Definition of Performance Measure 



o 

Experimental Verification and Compliance 

e) 

Work Site 

o 

Lighting 



o 

Detector Configuration 



o 

Space Qualifications 



o 

Auto-focus and Auto-point 



o 

Number and Configuration of End Effectors 
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5.2 APPROACH 


In concert with the ROSS program development , development of the 
simulation tool will take place under three phases. The output of the 
Phase I level of effort will be the baseline hardware and software 
required to support a ground station design for the ROSS. Phase II 
simulation will support actual flight hardware and can be used to 
validate software models used in the simulation to represent actual 
hardware. Information obtained in Phases 1 and II will be incorporated 
to develop a high fidelity simulation that will support the deployment of 
the Remote Orbital Servicing System (ROSS). 

Activities to be performed under ROSS Phase I aire: 

1. Define initial configuration of ROSS ground station, procure, 
construct, and install equipment. 

2. Develop software models of components and subsystems of ROSS. 

3. Conduct lab tests of available components and subsystems and 
validate software models. 

4. Integrate developed models of ROSS into robotics simulation. 

5. Initiate evaluation of ROSS. 

Completion of these activities will result in initial ROSS evaluations. 

Phase II ROSS activities providing guidance and evaluation of ROSS 
during phase C/D and in evaluation of advanced subsystems are: 

1. Continue ROSS evaluations with modifications as defined from 
phase C/D and lab tests. 

2. Develop models of components and subsystems resulting from base 
technology programs. Install in robotic simulation, validate, 
and conduct parametric analysis at systems level to define 
benefits and required modifications or improvements. 

3. Modification of ground control station to allow reconfiguration 
to conduct basic tests of man/machine Interface. 

4. Final ROSS configuration modification, validation, and operator 
training. 

5. Research in enhancement to ROSS concept for future missions. 

The ultimate goal of the simulation will be accomplished at the 
completion of the Phase III level of effort. By completing this phase, a 
simulation will exist that has the following properties: 1) validated 

simulation which can be used to evaluate the teleoperator and robotic 
system and 2) provide a research tool to be used to design, develop, and 
deploy man/ machine systems used in conjunction with remote manipulators. 
Activities to be performed under this phase are summarized below: 
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1. Incorporate vehicle dynamics for capture, docking, and 
stabilization. 

2. ROSS training and mission support. 

3. Final validation of ROSS using flight experiment results. 

4. Perform research on next generation servicer and space 
construction using remote systems. 

When properly designed, the simulation can be used to: 1) aid in 

requirements analysis and conceptual design, 2) hardware and software 
design verification, 3) personnel training, and 4) mission support and 
assessment. In performing these activities, the simulation can be used 
to define and allocate man/machine functions. The operational mode of 
each task function will be designated as being either manual, semi- 
automatic, or automatic. 

Associated with the five activities which support man-in- the-loop 
simulations, certain simulation utility tasks will be required. Varying 
degrees of fidelity will be required to accomplish these tasks. Table 
5-2 presents these relationships. 

From heuristic arguments, it can be shown that a simulation provides the 
foundation for the ground control station configuration (GCSC) . 
Examination of Figure 5-1 shows the GCSC evolution from a digital 
simulation. As shown in this figure, a digital simulation of the 
teleoperator in conjunction with the manipulator d}mamics will lead to 
the software requirements necessary to support the ROSS mission. In 
addition to providing a high fidelity model of the entire system, the 
digital simulation will also identify the critical parameters, give an 
analytical definition of the system requirements, provide a mechanism for 
allocating error budgets, give an upper bound on system performance, and 
aid in the design of flight experiments. 

Having determined the optimal performance of the ROSS system with the 
digital simulation, components of the system can be developed. For 
example, the manipulator dynamics would be replaced by the actual 
manipulator itself. Also, analog components such as a hand controller 
would be augmented with digital components ultimately creating a hybrid 
simulation. The output of such a hybrid configuration would be the 
hardware and software which would serve to baseline the GCSC. 

Payoffs other than the HW/SW requirements of the hybrid simulation are: 

1) verification of the digital models, 2) provide a measure of system 
component compliance to specifications, 3) provide a measure of the 
ability to control a mechanism from a remote observation post, and 4) 
provide an aid to the design of experiments to be conducted. 
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Table 5-2 Man-in- the- loop Simulation Activity 


ACTIVITY 

SIMULATION UTILITY TASKS 

SIMULATION FIDELITY PHASES 

Requirements Analysis 
and Conceptual Design 

0 

Conceptual Development 

0 

Functional Simulation 


0 

Allocation of Functions 
Between Man and Machine 

0 

System Modeling 




0 

Subsystem Modeling 


0 

Feasibility Demonstration 


Component-Level Modeling 





Hardware and Software 
Design and Development 

0 

Analysis of System Performance 




0 

Development of Controls and 
Displays 




0 

Development of Flight Experiments 



Hardware and Software 

0 

Functional Verification 

0 

Breadboard Hardware and 

Design Verification 

0 

Subsystem Compliance 


Software 




0 

Prototype Hardware and 


0 

Mission Timelining 


Software 


0 

Development of Procedures and 
Checkl ists 



Personnel Training 

0 

Personnel Selection 

0 

Flight-Type Hardware and 
Software 


0 

Part Task Training 




0 

Full Up Training 



Mission Support and 
Assessment 

0 

Real-Time Mission Support 




0 

Post Flight Analysis 







F'igio'e 5-1 Si-mulation: A Foundation for the GCSC 
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6.0 


CONCLUSIONS AND RECOMMENDATIONS 


The current phase of development (Phase I) has provided an evaluation 
of artificial Intelligence techniques, a computer program framework, 
some basic capabilities for the ROBSIM program, and study Into 
manipulator control techniques. Future work (Phase II and III) will 
Include several study areas as well as enhancement and expansion of 
computer capabilities. 

Short-range (Phase II) expansion of the ROBSIM capabilities will be 
conducted throughout the remainder of FY1982. Four major areas are to 
be considered: 

1) Investigate trajectory planning modules (collision avoidance, 
minimum energy, other constraints); 

2) Develop video simulation and Image processing modules; 

3) Define Interactive Initialization program modules; 

4) Identify benefits and limitations of control laws. Including both 
classical and modern control techniques. 

Several enhancements and expansions are planned for computer 
capabilities. The system definition capability will be expanded to 
provide more detailed system component Input. A library of parts will 
be started to store data describing frequently used components. 

Graphics capabilities will also be expanded. The force/torque 
requirements analysis tool will be expanded to provide for external 
forces and torques, rate and position limit checks, and multiple arm 
capability. The simulation tool will be expanded from a single-joint 
model to a two-link model. Complete dynamics for the two-link case 
will be added. The two-link case will then be used for control 
technique studies. The postprocessing capabilities will be expanded to 
handle Input from multiple analysis tool executions. 

Long-range (Phase III) expansion of the ROBSIM capabilities (FY1983 and 
beyond) will be directed primarily toward supporting teleoperator and 
robotic systems capable of remote space operations, l.e., the Remote 
Orbital Servicing System (ROSS) concept. In FY1983, It Is proposed to 
Incorporate software modules for the total simulation of the ROSS 
concept Into the simulation framework. The simulation framework will 
be expanded In the areas of actuator, sensor, and mobility system 
modeling; the ability to simulate multiple arm configurations; and a 
parts library. Mathematical models of the components and subsystems of 
ROSS will be developed and Incorporated Into the ROBSIM framework. The 
ROSS subsystems to be modeled will Include the vehicle dynamics, the 
manipulator system, and the flight sensors. This activity will require 
expanding the ROBSIM framework to include multiple arm configurations 
and modeling of the host vehicle. For the specific ROSS configuration. 
It is anticipated that the models for the manipulator motors, the 
sensors, and the end effector are sufficiently different from existing 
models to warrant developing new software modules. However, the mass 
properties, physical dimensions, and joint configurations can be 
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directly Incorporated Into the existing dynamics models. Also included 
under the FY1983 activity, laboratory experiments should be conducted 
to validate software modules and to define hardware requirements for 
the ground control station for manned control of the ROSS. 

The trajectory planning technique defined under the Phase II activity 
should be Implemented and Incorporated into the ROBSIM framework. The 
trajectory planning module will perform obstacle avoidance, optimal 
trajectory planning, and singularity avoidance. The man-machine 
interface, coupled with software-simulated remote systems, would then 
be in place to evaluate teleoperator and robotic systems capable of 
remote space operations. 

Various approaches to autonomous task planning should also be studied. 
Task planning is one level of sophistication above trajectory planning 
where the system solves the subtle problems associated with task 
scheduling to achieve a specific mission goal. Techniques to be 
considered Include directed graph theory, rule-based systems, and 
theorem provers. 

Continued development during Phase II and Phase III may be carried out 
on virtually any modern digital computing machine of the super-mini and 
higher class. However, with the exception of the newest and fastest 
machines, the necessary processing will not be accomplished in real 
time by a single machine. Specialized machines with multiple processor 
architectures will be necessary for the accomplishment of this goal. 
Areas such as mechanical configuration optimization, accuracy analysis, 
control requirements and stability studies, and work environment 
studies may require simulation but not necessarily in real time. 

If real-time solutions of the simultaneous simulation equations are 
determined not to be necessary, the continued development on the VAX 
11/780 is quite appropriate. However, it should be pointed out that 
there are several significant downstream requirements pointing to a 
need for a real-time simulation associated with a hardware development 
program such as ROSS. Some of these are: 

1) Realistic Graphics - When the simulation system is coupled with a 
graphic display of the computer solutions in real time, the results 
are much more realistic. 

2) Surrogate Hardware - Properly-simulated hardware may be used to 
replace hardware subsystems that have failed or are not yet 
available. The remainder of the hardware may be used in the system 
as intended. System problems may be Isolated by substituting 
software modules for suspected failing hardware modules. System 
Integration may be approached more gradually by bringing hardware 
on line one module at a time or as the hardware is available. 

3) Real-Time Test Bed for Algorithm Development - Control and 
estimation algorithms may be evaluated and optimized using the true 
or emulated control computer without the use of scaling within the 
algorithms and no potential damage to the existing manipulator 
assembly. 
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4) Real-Time Research Test Bed for Artificial Intelligence (AI) and 
Man/Machine Interface (MMI) - Safe, real-time response to decisions 
and trajectory definitions by the AI as dictated by sensor output 
and command input through the MMI is very important to these 
research areas. 

It should be emphasized that in order to achieve the goal of an 
operational robotic simulation, a large number of complex areas must be 
considered. Many of these areas are already provided for in the ROBSIM 
framework; others must be added as required. Table 6-1 provides a list 
of candidate areas for consideration. Areas such as sensor 
configuration and sensor data processing may present significant 
challenges in simulation. Other areas such as control, intelligence, 
and man/machine interface are expected to be research oriented and 
therefore somewhat fluid. All areas should be represented, even if 
only by simplified modules, in order to approach full-scale simulation. 


Table 6-1 Simulation Considerations 


A. Manipulator Configuration 

1. Joint Dynamics 

2. Joint Sensors 

3. Joint Actuators 

4. Manipulator Geometry 

5. Inner Loop Control 

6. End Effector 

7. End Effector Control 

B. Sensor Configuration 

C. Mobility Configuration 

1. Mobility Sensors 

2. Mobility Control 

D. Sensor Data Processing 

E. Control Philosophy 

F. Intelligence 

G. Man/Machine Interface 
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